Linksets direction DXL

llandale - Mon Jan 24 16:31:14 EST 2011
A "Link Module" is an actual module. You create LinkSets therein housing defining links between the LinkSet's Source and Destination modules.

The "LinkSets" tab in the Module Properties is poorly named, it should say "LinkSet Pairings". A "LinkSet Pairing" is just a piece of information defining into which LinkModule links may or must go. "LinkSet Pairings" are managed in the Module Properties in the GUI.

A "LinkSet" can be likened to a "Car", and a "LinkSet Pairing" likened to a "Parking Spot". "Take the car in spot 49"; "49" just tells you which car.

To make it more confusing, "LinkSet Pairings" in the GUI are called "LinkModuleDescriptors" LMDs in DXL. "LMDs" are actually stored in the folder housing the source module, they are NOT stored in the Source Module itself (as the GUI incorrectly suggests). There is thus a "for LMD in folder" loop.

• Louie

TooDifficult - Mon Jan 24 19:34:43 EST 2011
Pseudocode

//create module (link module)
//create linkset pairing using LMD functions
//set linkset module to be default
//set all links to go through this default linkmodule

is this right?

Thanks,

TooDiff

llandale - Tue Jan 25 09:24:10 EST 2011
Sadly, I don't actually create many links so I may be wrong here. No, the user's 'Default link Module' typically "DOORS Links" is pretty worthless. That's just where you create links when you fail to specify a link module. I believe the LSP/LMD pairings take precedence, so the 'Default link Module' won't come into play. When I grow up I'm going to set everybody's Default link Module to perhaps "/Silly Default Links"; taking note of the slash, which will put them ALL into a single module at the Project root. "DOORS Links", taking not of no slash, will end up creating a new such module in whatever fold is current; causing LOTS of such link modules around the database.

I don't recall the exact rules for 'Mandatory' and 'Overrideable', but 4 years ago when I went through it, it was not clear. You need to play with those settings; where only 3 of the 4 possible combinations was legal ON-ON, ON-OFF, OFF-ON, OFF-OFF; don't recall which one was illegal.

there is also a module-level flag that can insist that ALL links go through some LSP, so if you fail to specify you cannot create any links.

I'm sure you need to get this understood using the GUI and get your desired process in place before ever bothing to try to manage it in DXL.

• Louie

SystemAdmin - Tue Jan 25 15:58:28 EST 2011
"....ON-ON, ON-OFF, OFF-ON, OFF-OFF; don't recall which one was illegal...."

The illegal one is ON-ON

Mandatory: The linkset pair rule cannot be avoided. DXL scripts or link menu items that attempt to use a different link module will fail - those attempting to do this will be dealt with in the appropriate manner:-)

Overrideable If the user has a default link module defined in their user profile, the linkset pair rule will be ignored and the users default used instead (avoid this option, it can ruin a good day!)

They both cannot be ON because it's a contradiction of logic if you were to able to override a mandatory rule - unless of course you are in politics :-)

"there is also a module-level flag that can insist that ALL links go through some LSP, so if you fail to specify you cannot create any links."

This module level flag set to ON is must have and should be a default setting on modules - I would rather have a user complain that they can't create any links and spend 5 minutes setting up the linkset pair rules than have to spend hours cleaning up the linking mess later.

PDU - Wed Jan 26 01:39:43 EST 2011
Paul, this is very interesting.

The "module-level flag" : is it the "Only allow outgoing links as specified in the above list" in the linkset tab of module properties?

Is it possible configure database to have all modules with this flag and with all linkset "mandatory".

Or when I create a module by code, is it possible configure these properties ?

Pierre

SystemAdmin - Wed Jan 26 01:57:38 EST 2011
"The "module-level flag" : is it the "Only allow outgoing links as specified in the above list" in the linkset tab of module properties?"

Yes

"Is it possible configure database to have all modules with this flag and with all linkset "mandatory"."

There is no DB wide configuration setting for the linkset pair options, they have to be set on a module by module basis and the default for all of them is disabled

"Or when I create a module by code, is it possible configure these properties?"

Yes - look up the DXL Reference Manual (under the Help menu) and go to the section Links>Link Management and look for the functions addLinkModuleDescriptor, setOverridable, setMandatory and setLinkModuleDescriptorsExclusive

SystemAdmin - Tue Jan 25 15:58:28 EST 2011
"....ON-ON, ON-OFF, OFF-ON, OFF-OFF; don't recall which one was illegal...."

The illegal one is ON-ON

Mandatory: The linkset pair rule cannot be avoided. DXL scripts or link menu items that attempt to use a different link module will fail - those attempting to do this will be dealt with in the appropriate manner:-)

Overrideable If the user has a default link module defined in their user profile, the linkset pair rule will be ignored and the users default used instead (avoid this option, it can ruin a good day!)

They both cannot be ON because it's a contradiction of logic if you were to able to override a mandatory rule - unless of course you are in politics :-)

"there is also a module-level flag that can insist that ALL links go through some LSP, so if you fail to specify you cannot create any links."

This module level flag set to ON is must have and should be a default setting on modules - I would rather have a user complain that they can't create any links and spend 5 minutes setting up the linkset pair rules than have to spend hours cleaning up the linking mess later.

llandale - Wed Jan 26 11:45:40 EST 2011
'Overrideable' means it WILL use DOORS Links, or CAN use DOORS links? If its "WILL", then I don't see the purpose of the LinkSet pairing.

What does it mean when a LinkSet pairing is neither 'Mandatory' nor 'Overrideable'?

• Louie

llandale - Wed Jan 26 11:45:40 EST 2011
'Overrideable' means it WILL use DOORS Links, or CAN use DOORS links? If its "WILL", then I don't see the purpose of the LinkSet pairing.

What does it mean when a LinkSet pairing is neither 'Mandatory' nor 'Overrideable'?

• Louie

SystemAdmin - Wed Jan 26 16:48:01 EST 2011
'Overrideable' means it WILL use DOORS Links, or CAN use DOORS links?

Means it WILL use the default DOORS Links module or whatever default link module the user has defined for themselves under Tools>Options>Settings - if you try to set this option to nothing, DOORS automatically forces it back to "DOORS Links"

If its "WILL", then I don't see the purpose of the LinkSet pairing.

I agree - I assume that they are trying to cater for some sort of rare exception that I cannot fathom.

What does it mean when a LinkSet pairing is neither 'Mandatory' nor 'Overrideable'?

The only exceptions that I can think of where these two settings might make sense is when you want to have the option of overriding the linkset rule when using DXL scripts that create links or advanced link features such as Create Links and Link by Attribute. These two advanced features allow you to choose a specific link module as opposed to enabling the Overrideable option which only focuses on using the users default link module.

I don't like these shades of grey with linkset pairs, it should be absolutely black and white - if your going to use linkset rules, set each rule to "mandatory" and enable "Only allow outgoing links as specified in the above list". Deal with the linking exceptions when they happen, if they ever happen.

TooDifficult - Wed Jan 26 18:41:17 EST 2011
ooo nice info here

Ok so as per louie's suggestion of playing around with GUI links until I understand it...

I've done so and I think I've got a grasp of how it works. HOwever I still can't find the option that restricts the direction of where links can go.

I got the only allow outgoing links but I can still link back and forth between 2 modules.

Is it possible to only allow linking forward from A->B and not B->A

tooDiff

TooDifficult - Wed Jan 26 18:41:17 EST 2011
ooo nice info here

Ok so as per louie's suggestion of playing around with GUI links until I understand it...

I've done so and I think I've got a grasp of how it works. HOwever I still can't find the option that restricts the direction of where links can go.

I got the only allow outgoing links but I can still link back and forth between 2 modules.

Is it possible to only allow linking forward from A->B and not B->A

tooDiff

SystemAdmin - Wed Jan 26 19:22:22 EST 2011
TooDifficult wrote: Is it possible to only allow linking forward from A->B and not B->A

Yes - linkset rules can be defined in the context of what target modules is the current source module allowed to link to - here's how it's done w.r.t. your A and B example

In module A: Define a linkset rule that identifies B as the target module, and identifies which link module to use when linking from A -> B. Enable Mandatory, disable Overrideable options for that linkset rule, and enable the Only allow outgoing links as specified in the above list option which applies to all linkset rules.

In module B: The only thing to do is enable the Only allow outgoing links as specified in the above list option, no need to define any linkset rules because at the moment, B is not allowed to have links to any other target module.

The above arrangement sets the following link rules between A and B.

1 Links can be made from Module A (source) -> Module B (target) and link data will be stored in the designated link module when this happens.

2 Links cannot be made from Module B (source) -> Module A (target) because there are no linkset rules defined in B to support this, and the Only allow outgoing links as specified in the above list setting in B stops anyone from trying to get around this.

As time progresses, you may determine that there needs to be links to a 3rd module, Module C. Lets say links from B -> C in that direction. This would require a linkset rule to be added to Module B to support that arrangement, remembering to enable the Mandatory and disable the Overrideable options for that new rule and so on.

TooDifficult - Wed Jan 26 20:40:06 EST 2011
I see, it's clearer now.

However I was testing how the outgoing link force works, and what I got was (prior to creating any sort of linkset pairing):

Dragging A --> B to create a link worked (outgoing link).
Dragging B --> A to create a link also worked (outgoing link relative to B). Note that both of these modules have specify outgoing links only

Dragging from A-->A did NOT work because it was an 'internal link'?

So technically by only allowing outgoing links, I'm not restricting any direction at all, just preventing self-linking within one module.

When I introduce a linkset pairing, then self linking AS WELL AS a certain link direction A --> B is enforced.

As I set this to mandatory and non-overrideable, any link that says, B --> A will be prevented because:

1. Mandatory link module must be adhered to.
2. No such information regarding linking B to A, only A to B.

In which case neither B-->B nor B-->A will work, because I have banned self linking and only allowed A-->B

Am I correct? It's quite confusing

SystemAdmin - Wed Jan 26 21:53:05 EST 2011
In which case neither B-->B nor B-->A will work, because I have banned self linking and only allowed A-->B. Am I correct?

Yes - however, you can still allow internal linking within a module by defining a linkset pair rule where the target module is the source module itself.

...do you have to create a different link module for different link directions?

No - Link Modules are just a repository used to store link data between a source module and a target module - where each source to target pair is known as a linkset. You can stuff all link data in one link module if you wish but this is bad practice.

The best practice is to create link modules for each major linking relationship - for example links between System level Specs and Sub System Specs, links between System Level Specs and Design Documents etc. Link modules are named according to the link relationship that they will manage - for example - "System to Sub-System Links" or "Satisfies" or "Verifies" or whatever. By doing this, you have far greater control over the management of links in terms of managing access rights to linking, being able to differentiate links when using the link filtering features of DOORS and many other benefits.

Link modules are a throw back from earlier versions of DOORS. They are slowly becoming more and more unnecessary and will hopefully eventually disappear once features like linkset pair rules and others become a little more sophisticated.

TooDifficult - Wed Jan 26 20:33:50 EST 2011
Should edit my previous post:

What I meant was, do you have to create a different link module for different link directions?

What if I linked CRD --> MRD in that specific direction only, but I also had REG --> FMEA store information in that same link module?

I could right? Since a link module would have a bunch of specific pairings for each module:

CRD --> MRD
REG --> FMEA

All I have to do is get the REG --> FMEA to create a linkset pairing, and the new linkset information would be stored in the link module automatically?

TooDiff

llandale - Thu Jan 27 13:23:43 EST 2011
Lets take a step back. The vast majoriy of us agree that you "should" create a Link Module in the Project for each "kind" of relationship you wish to allow. So if you want to represent "Traceability", "Verification" relationships you may have two link modules.

Using the GUI and DXL, you can use the link module name as a mechansim for defining what the relationship means; "object A links to B" is not nearly as useful as "object A 'Satisfies' B". The first is the best you can say if the links are in some random module, the 2nd you can say if the link is in the "Traceability Links" module. You an add Layouts and AttrDXL that say "Show me all the traceability decomposition".

Might as well put these link modules in their own "/Link Modules" folder.

Given that schema, when A links to B in a particular module it will rarely make sense that B could also link to A in the same link module. Surely if "A 'satisfies' B" then it cannot be also that "B 'satisfies' A". Likewise if "A Tests B" then "B cannot Test A". The exception to this is when you have some sort of "References" relationship; but even then its questionable. "A References B" then you can deduce "B is Referenced by A" by looking for incoming links.

You would create link-sets in your Link Modules as you create new Formal Modules that qualify for links; so when you create module SubSys2 you would create a LinkSet in the "Traceability" link module, defining links from SubSys2 to the System spec. You would then presumably use the GUI to create a LinkSetPairing in SubSys2, defining such links to the System spec in that actual LinkSet.

• Louie

llandale - Thu Jan 27 13:23:43 EST 2011
Lets take a step back. The vast majoriy of us agree that you "should" create a Link Module in the Project for each "kind" of relationship you wish to allow. So if you want to represent "Traceability", "Verification" relationships you may have two link modules.

Using the GUI and DXL, you can use the link module name as a mechansim for defining what the relationship means; "object A links to B" is not nearly as useful as "object A 'Satisfies' B". The first is the best you can say if the links are in some random module, the 2nd you can say if the link is in the "Traceability Links" module. You an add Layouts and AttrDXL that say "Show me all the traceability decomposition".

Might as well put these link modules in their own "/Link Modules" folder.

Given that schema, when A links to B in a particular module it will rarely make sense that B could also link to A in the same link module. Surely if "A 'satisfies' B" then it cannot be also that "B 'satisfies' A". Likewise if "A Tests B" then "B cannot Test A". The exception to this is when you have some sort of "References" relationship; but even then its questionable. "A References B" then you can deduce "B is Referenced by A" by looking for incoming links.

You would create link-sets in your Link Modules as you create new Formal Modules that qualify for links; so when you create module SubSys2 you would create a LinkSet in the "Traceability" link module, defining links from SubSys2 to the System spec. You would then presumably use the GUI to create a LinkSetPairing in SubSys2, defining such links to the System spec in that actual LinkSet.

• Louie

mtmccor - Wed Apr 27 10:53:33 EDT 2011
I have not kept up with the DXL forum for a few months, so that is the reason I am so late in adding my thoughts to this thread.

Note the problem with the LinkSetPairings restriction, you may specify only a single LinkSet from module A to B
If you do have multiple different relationships between two modules, then link attributes can be used to indicate the different relationships. I know I have seen a previous thread awhile ago that recommended not using link attributes because they are more difficult to access for setting and seeing the values, but they can be useful if used judiciously and limitedly. The link attribute is defined in the link module.

Two examples (simplified for posting purposes) of where we used link attributes are
1. We have a module of cable connector definitions. We have several component requirements modules with connection requirements that need to indicate the beginning connector and the ending connector. Our link module from requirement module to cable connector module is uses, and it has a link attribute called EndpointType which is an enumerated type with values of begin and end. So we link from a requirement to a cable connector object and set the link attribute to either begin or end.

2. We have a Record of Decision module and a People module. The Record of Decision module links to the People module through the participated_by link module so that we can show who was involved in the decision. We also want to know who is the point-of-contact for the decision, so the link module has a POC link attribute with possible values of yes or no, default no. This is set to yes on the link to the person that is the POC.

PDU - Wed Jan 26 02:30:03 EST 2011

Thanks Paul,

i have modified the code that we used to generate formal modules with

//####  only allow outgoing links as specified in the above list 
Folder f = current 
ModName_ mName = module(m."Name" "")
setLinkModuleDescriptorsExclusive(f,mName, true)

Fine.

Pierre

roloenni - Tue Apr 28 10:50:46 EDT 2015

Can you help me with a code that will uncheck "Only allow outgoing links" for all modules in a folder?

Thanks Rolf